Development framework for case and workflow systems

ABSTRACT

A workflow processing framework provides common objects and business processes for the creation of an enterprise-wide workflow processing system. Conventional workflow, database and other platforms are accessed using standardized protocols. The use of common objects providing robust functionality while being insulated from the specific platforms used to implement the workflow processing system enable the common objects to be reused to perform many functions in many different lines of business without modification. If necessary, foundation objects are written to utilize the existing platforms more fully than permitted by standardized protocols. The business processes are generalized as much as possible, but are customized as required to fit the enterprise environment.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation of application Ser. No.09/166,120, filed Oct. 15, 1998, now allowed.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention is directed to automated workflow systemsand more particularly, to an object-oriented framework used indeveloping and implementing consistent workflow systems in a singledepartment or throughout an enterprise, such as a corporation or agovernment agency.

[0004] 2. Description of the Related Art

[0005] Computer programs have been written for businesses since the1950's and 1960's using first machine code, then assembly languages,COBOL, and third, fourth and fifth generation languages. Most work inoffices uses at least one and often several computer programs, includinglanguages and software tools that are used in many different industries,such as word processing, spreadsheets, databases, etc., toindustry-specific or line-of-business programs, many of which are usedto manage the work performed in a specific industry or within certainparts of an industry. In the 1980's, imaging began to be used to supportline-of-business programs, reducing the amount of paper required toperform the business functions by storing the paper image in thecomputer as part of the business program. In the late 1980's, companiessuch as Filenet, IBM, Wang, etc., developed workflow products of varioustypes. At first, workflow processing products were added to imagingsystems in an effort further the “paperless office”. Workflow wasattached to image-enabled systems because the presence of the electronicimage (as opposed to the paper document) allowed the workflow system to“push” work to users in addition to using “pull” technology. With anelectronic image, the image could be presented to the user when the workwas pushed to them; if paper was required, pushing work to an individualrequired that the individual then physically retrieve the paper when thework item was pushed to them. Workflow systems developed along severaldimensions: “collaborative workflow” was developed to support ad hocworkflow requirements—where the knowledge worker developed a workflowbased on the characteristics of each business case; “embedded workflow”was developed to support simple workflow requirements that are arequired part of business systems; and “mission critical” workflow wasdeveloped to support high volume, predictive workflows.

[0006] Management of “mission critical” work in an organization requiressignificantly more than the features provided by embedded andcollaborative workflow systems. A type of workflow processing systemtermed “utility” systems combine complex process rules stored in adatabase, existing system interfaces, and user interfaces that controlwhat is available to a worker at a computer workstation or terminal, andmay monitor the work being performed.

[0007] Three types of utility workflow processing products have evolved.The first products that were commercially available were developmentlanguages developed to support workflow. Instead of using generaldevelopment languages (e.g., COBOL, Basic, Fortran), these workflowlanguages were developed to facilitate the programming of workprocesses, much as specialized development languages were developed forsuch functions as artificial intelligence (e.g., LISP) and processmanufacturing. Examples of these “general purpose” workflow languagesinclude FileNET's Visual WorkFlo, IBM's Flowmark, and Staffware'sStaffware. Some of these products support a wide range of capabilitiesand functions for the enterprise, some are focussed on a smaller set offunctions and smaller user implementations.

[0008] The other two types of utility workflow that have evolved includeworkflow that is specific to a line-of-business or application andworkflow that has been added to a suite of business applications.Examples of the former include templates for various financialapplications from Pegasystem, mutual fund applications from DST Systems,Inc, and Banctec's Plexus applications for the financial servicesindustry. In these applications, business specific workflow rules andprocesses are provided as a full or partial solution (often referred to,respectively, as a package or a template). Some of these solutions arebuilt using general purpose workflow development languages, some havebeen built using custom workflow languages. The workflow supported bythis class of systems is typically hardcoded (necessitating codingchanges to programs written in general purpose programming or workflowlanguages when changes are required) and supports only the specificworkflow functionality required by the application. However, even if theworkflows are offered for a range of business functions, they do notutilize the same process definitions and code; at best they reuse thecode, at worst the code is unique for the line of business.

[0009] Examples of the third type of workflow solution include financialand enterprise resource planning (ERP) suites such as those from Oracle,Baan, and Systems, Applications, and Products in Data Processing (SAP).These application suites often share data and functions across the linesof business, but only support rudimentary workflow functions and shouldnot be characterized as mission critical workflow. They are included inthis category only because they are marketed as mission criticalsolutions.

[0010] The state of the art is that there are powerful workflow toolsetsthat require specific products to support their use and enable a user tocreate a customized workflow processing system with significant effort.There are also many products designed for specific applications withinan industry that can be customized with varying amounts of effort.Examples in the claims processing area include Quick Start for DataEntry from American Management Systems and similar products from IPD,Image Matrix, and others.

[0011] However, there are no scalable products designed to providestandardized workflow processes in a department or throughout anenterprise, that are applicable across industries; provide the codingefficiency of object-oriented design; and utilize open standards to workwith existing third party tools and languages, such as databases,graphical user interface languages, etc., currently in use or desired tobe used by the organization implementing the workflow processing system.

SUMMARY OF THE INVENTION

[0012] Additional aspects and/or advantages of the invention will be setforth in part in the description which follows and, in part, will beobvious from the description, or may be learned by practice of theinvention.

[0013] It is an object of the present invention to provide a frameworkfor developing a workflow processing system using object-oriented designprincipals to minimize coding effort and maintenance requirements inimplementation in individual departments and throughout an enterprise.

[0014] It is another object of the present invention to provide aworkflow processing framework utilizing existing third party tools andlanguages through adherence to standards and an open architecture.

[0015] It is a further object of the present invention to provide aworkflow processing framework that enables users to define logicalqueues through dynamic work divisions without requiring coding changesto programs written in programming languages.

[0016] It is a yet further object of the present invention to provide aworkflow processing framework that can operate on folders containing anytype of data accessible in electronic form and prefetch the data withoutrequiring knowledge of how to access and utilize the specific type ofdata by the user defining what is included in a folder.

[0017] The above objects can be attained by a workflow processingframework, scalable for use by a single department to an entireenterprise, including a set of software objects, each unique throughoutthe enterprise, to support corresponding business functions; a database,accessed by a subset of said software objects, defining work taxonomyand work steps for workflow processing; and a workflow engine utilizingsaid software objects and the work taxonomy to perform the workflowprocessing. The workflow processing framework can be used to develop aworkflow processing system by entering data into the database to definework types and work steps for workflow processing, creating a graphicaluser interface (GUI) to use the set of objects, and defining theworkflow in the workflow engine.

[0018] These together with other objects and advantages which will besubsequently apparent, reside in the details of construction andoperation as more fully hereinafter described and claimed, referencebeing had to the accompanying drawings forming a part hereof, whereinlike numerals refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] These and other aspects and/or advantages of the invention willbecome apparent and more readily appreciated from the followingdescription of the aspects of the present invention, taken inconjunction with the accompanying drawings of which:

[0020]FIG. 1 is a three-dimensional illustration of types ofapplications, types of functions performed in each application andinformation used in carrying out those functions in a workflowprocessing system.

[0021]FIG. 2 is an overview of the application program code in aworkflow processing system according to the present invention.

[0022]FIG. 3 is a more detailed block diagram of the objects andbusiness processes in a workflow processing framework according to thepresent invention.

[0023] FIGS. 4A-4C are a hierarchical diagram of objects in a workflowprocessing framework according to the present invention. FIG. 5 is aflow diagram of events processing and queue assignment in a workflowprocessing system according to the present invention.

[0024]FIG. 6 is a flowchart illustrating an example of workflowprocessing according to the present invention.

[0025]FIG. 7 is a block diagram of a workflow processing systemaccording to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Reference will now be made in detail to the embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings, wherein like reference numerals refer to like elementsthroughout. The embodiments are described below in order to explain thepresent invention by referring to the figures.

[0027] There are several drawbacks in the state of the art of workflowprocessing development systems. Existing toolsets can be used togenerate many types of systems, but the effort required for an entireenterprise would be only a slight improvement over using general purposeprogramming languages from scratch since many workflow functions wouldneed to be built for each and every individual application. Existingtemplate products are similarly designed for small-scale applicationsand are not powerful enough to serve a variety of workflow processingapplications throughout an enterprise. Many of the currently availableproducts are generally proprietary in nature, i.e., they are easily usedonly with products from the same vendor or a small number of third partyvendors or in specific lines-of-business. The remaining products weredesigned with such a narrow focus that the products cannot easily bescaled to serve a variety of types of workflow processing.

[0028] The three-dimensional drawing in FIG. 1 provides an illustrationof how limited prior art workflow processing systems are compared to thepresent invention. Along the horizontal axis are examples of fourdifferent workflow processing systems that have been developed for theinsurance industry. The illustrated examples of “line of business”functions, are processing of insurance claims, new businessunderwriting, customer service and annuity processing. Examples in otherindustries are credit card fraud processing, credit applicationprocessing, medical records processing, dispute processing, etc.Illustrated along the vertical axis are some of the functions typicallyperformed by these existing systems: routing, workload balancing, andquality assurance.

[0029] As in the case of “line of business” products, the prior artincludes cross-functional workflow processing systems like thosearranged along the vertical axis. Generic accounts payable systems areavailable in the form of templates from Unisys and Crowe Chisek.Similarly, workflow processing systems capable of being used for callcenters are available from Pegasystems and Mosaix as well and routingproducts are available from middleware vendors such as Hewlett-Packardand Early Cloud (now owned by IBM).

[0030] Typically, the data operated on by workflow processing systems isdetermined when the workflow processing system is designed and islimited to a few types, such as database records, electronic documents,e.g., word processing documents, and images, such as TIFF Level 4, GIF,JPEG, etc. for images, CAD drawings, medical X-rays, etc. As describedbelow, the present invention is designed to handle all known data typesand is flexible enough to add additional data types with minimal changesto the framework of objects used by the present invention.

[0031] If existing prior art systems were mapped onto thethree-dimensional drawing illustrated in FIG. 1, the systems would useonly two dimensions and fill a small amount of space in thosedimensions. For example, an insurance claims workflow processing systemwould include the functions of automated work distribution, documentrendezvous, work step division, and letter generation. Similarly, anaccounts payable system might be limited to electronic documents andimages of the types of data illustrated in FIG. 1, depending upon how itis designed, but would be unlikely to include data records, audio orvideo.

[0032] The present invention uses a set of software objects, eachuniquely performing a corresponding function in a workflow processingsystem and a set of process definitions, accessed by a subset of thesoftware objects, to provide a flexible workflow processing system thatcan be expanded in any of the three directions illustrated in FIG. 1.The software objects are designed to be generic and provide robustfunctionality. Tables are used to specify the functions performed by theobjects. This design enables the framework to be expanded easily in anyof the three directions illustrated in FIG. 1. Objects in the core aresufficiently generic so that they can be used in workflow processingsystems for any line of business that can be mapped to a case paradigm.The functionality provided by the objects is broad enough to apply tomany different line-of-business functions, including the threehorizontal applications illustrated in FIG. 1, as well as child welfarecase processing, telephone bill presentment processing, health claimsprocessing, dispute processing, fraud recovery processing, newapplication processing, return mail processing, and many more.Additional processes are written around the core of objects to customizea workflow processing system for a specific enterprise environment, asdiscussed with respect to FIG. 2.

[0033] The relationship between the objects in a workflow processingframework according to the present invention and the peripheralprocesses is illustrated in FIG. 2. At the bottom level are conventionalplatforms 20. Examples of platforms that may be used to support workflowprocessing include a workflow engine, like FileNET Visual WorkFlo,development languages, databases or data warehouses, existing imagingsystems, existing systems of record, etc. These conventional platforms20 may run on any type of computer system that has communicationcapability, including Windows, UNIX, or any mainframe operating system.A set of foundation objects 22 access the conventional platforms 20using standardized protocols whenever possible. For example, theframework preferably uses Distributed Component Object Model (COM/DCOM)in a Microsoft Windows 32-bit operating system to communicate with theworkflow and imaging engines using FileNET Panagon and databases usingActiveX Data Objects (ADO). DCOM enables the workflow processing systemto create and interact with software objects on separate computers in aprogramming language neutral and operating system neutral manner.

[0034] The foundation objects 22 are illustrated separately from theobjects 24 providing common functions in support of differentapplications, because in a specific enterprise environment standardizedprotocols may not be available and the foundation objects may need to bemodified to utilize conventional platforms 20 existing in the enterpriseenvironment or previously selected for use with the workflow processingsystem. For example, in the exemplary embodiment of the presentinvention described below, FileNET Visual WorkFlo is used as theworkflow platform included in conventional platforms 20. However, onlythe foundation objects 22 have to be changed to accommodate the use of adifferent workflow platform.

[0035] The objects 24 providing common functions in support of differentapplications provide “foldering” of materials (such as electronicdocuments, images, data records, etc.) used by each case and workflowfunction, including folder manipulation, rules based folder queuing andsubsequent retrieval, distribution, event triggering, etc. Businessprocesses 26 written in conventional programming languages performenterprise specific functions. The business processes 26 may be writtenin a variety of programming languages, such as Microsoft Visual C++,Microsoft Visual Basic, Sybase PowerBuilder, or Active Server Pages(ASP). A graphical user interface (GUI) is included in the businessprocesses 26, so that a human worker using the workflow processingsystem is presented with a computer desktop display consistent withother programs in use at the enterprise. Business processes 26preferably include modules that can be reused in many enterprises withvery little customization. The use of tables, as described below,minimizes the amount of customization of many of the business processes26. The architecture illustrated in FIG. 2 is used to support differentapplications. Different applications and different users would utilizedifferent subsets of the business processes 26, common objects 24,foundation objects 22 and conventional platforms 20.

[0036] Common objects 24 and business processes 26 are illustrated inmore detail in FIGS. 3 and 4A-4C. A hierarchical diagram showing therelationship of the common objects 24 and foundation objects 22 isprovided in FIGS. 4A-4C. FIG. 3 provides an overview of common objects24 and business processes 26. In the preferred embodiment, the workflowprocessing framework uses the case paradigm and thus, the first threeobjects in the middle row are Case Session, Case, Case Item and CaseWorklist. As described below with reference to FIGS. 4A and 4B, CaseItem is preferably included in the Case class, but is such an importantobject that it is included in FIG. 3. Other common objects includeSecurity, Expression Evaluator, Error Logging, Debug Logging, StatisticsLogging, and DataBase Connector. Foundation objects 22 that areproduct/vendor specific are called by some of these objects, such asDatabase Connector and possibly Error Logging if there are standards setby the enterprise for how errors are handled. The common objects aredescribed below in more detail with respect to FIGS. 4A-4C.

[0037] Business processes 26 are preferably C++ modules that may need tobe modified in a specific enterprise environment. Starting on the rightof the top row in FIG. 3, the Graphical User Interface will almostalways be further developed when a workflow processing system accordingto the present invention is implemented, so that the user interface iscustomized for the specific enterprise environment. As described belowin the example illustrated in FIG. 6, the remaining business processes26 use tables to minimize the amount of customization required, but mayrequire modification depending upon the type of information and how theinformation is handled. These tables essentially contain rules on howthe data is handled and thus, the Queue Assignment module can beconsidered specific implementations of a rules processor. The CaseBuilder module embodies specific business rules through customization.The Events Processor module matches incoming events with pending eventsby comparing event code values customized for each business. The UserAssignment module provides balanced distribution of work based on eachuser's load factor stored in a database table.

[0038] The following description of these business processes is done incontext of a typical workflow system. The Case Builder is used todetermine either when to create a new case or when and how to rendezvousan incoming document with an existing case folder. The Events Processor,on the other hand is executed whenever an event occurs that requires achange in workflow. An event can be any change by a worker (user of theworkflow processing system) or system module, or the expiration of atimer. The Events Processor is scheduled at intervals throughout theworkflow. One of the events that the Events Processor executes is thecreation of a new case from Case Builder. After the Events Processor hasdetermined the reason for moving the case folder through the workflow,Queue Assignment is executed to determine in which work step divisionthe case should be processed. Finally, if the workflow processing systemrequires that the determined work step division should have usersassigned to the cases, the User Assignment module is executed.

[0039] As illustrated in FIGS. 4A-4C, most of the common objects 24 arecollected in a parent object BLCaseSession 60. The two basic functionsperformed by the common objects are GetFilteredWorkList, GetUserWorkListand GetCase which results in the creation of BLCaseWorkList 62 andBLCase 64 objects. The other objects at the same level as BLCaseSession60 include BLDBConnMgr 66 which provides access to databases in theconventional platforms 20 as required by the objects in BLCaseSession60. The object BLConfigParam 68 provides an interface with the operatingsystem configuration information. In the preferred embodiment,BLConfigParam 68 accesses the Windows Registry to obtain parameters usedby the workflow processing system. Next are three objects that performlogging for debugging, error handling and statistics; BLDebugLog 70,BLErrorLog 72 and BLStatLog 74.

[0040] Of the final two top-level common objects, BLProgramSecurity 76and BLCoreInstMgr 78, the first performs an important function inworkflow processing and the second is used to manage instances ofobjects that are created by the workflow processing system.BLProgamSecurity 76 determines the access of an individual user or groupof users to functions within the workflow processing system. There arethree levels of security. The first type of security is the applicationwith which the user is permitted to work. For example, a typical workermay only use the insurance claim application illustrated in the lefthand column of FIG. 1, or the loan applications processing in the nextcolumn of FIG. 1, but not both.

[0041] The second type of security is the task of the user, e.g.,process claim 1, process claim 2. The second type of security istypically used in a situation where a single user interface is createdthat operates in different modes. In this situation although there aredifferent work steps in the workflow, a single user interface may beused as the work step business application, with its configurationchanged for each different mode of operation. The tasks are defined inthe tables described later and are identified in a user record. Anexample of a user record is provided immediately below.

[0042] BL_USERPROFILE

[0043] SUSERID=juser

[0044] SUSERNAME=Joe User

[0045] BISAVAILABLE=Y

[0046] BL_PROGRAMSECURITY

[0047] SUSERID=juser

[0048] SPROGRAMNAME=Claim Processing

[0049] BL_TASKSECURITY

[0050] SUSERID=juser

[0051] SPROGRAMNAME=Claim Processing

[0052] STASKNAME=Claim1

[0053] BL_FUNCTIONSECURITY

[0054] SUSERID=juser

[0055] SPROGRAMNAME=Claim Processing

[0056] STASKNAME=Claim1

[0057] SFUNCTIONNAME=Write Custom Letter

[0058] The third level of security is the function within the task. Forexample, while a function such as Write Custom Letter may be included inan insurance claim application, only certain users might be allowed toaccess this function. Other workers would be limited to ordinarycorrespondence processing and customer service functions illustrated inFIG. 1, and perhaps additional functions not illustrated.

[0059] BLCaseWorkList 62 retrieves a prioritized worklist for a userwhen a worker starts a session with a workflow processing systemaccording to the present invention. The next case can be retrieved whilesimultaneously processing the current case by user interaction through aclient/server GUI environment. Ordinarily a user will require a fewminutes to process the work item. During that interval BLCaseWorkListprefetches the next case to the client workstation of the user. Thislimits the idle time of employees between and during cases and increasesthe output of the employee.

[0060] BLCaseWorkList 62 is a multi-threaded COM object that operates ina producer-consumer environment. This object keeps track of the currentand next case objects using semaphores, threads, and class membervariables. The consumer thread is the normal user thread ofBLCaseWorkList 62. From the consumer thread the current case is obtainedfrom the list. The producer thread executes as long as BLCaseWorkList 62exists in memory. Whenever the next case object is NULL, the producerthread retrieves the next available case from the database. Whenever thenext case object exists, the producer thread does not try to get anothercase until the current case is retrieved into processing by the consumerthread.

[0061] Whenever a case is retrieved from the database platform inconventional platforms 20, a prefetch of that case is completed. Theprefetch function has an enumerated type which allows the system todetermine what components of the case need to be prefetched. Theenumerated type allows the system to filter (include or exclude) eachcase level component type individually in the prefetch operation. Thisprefetch filter value is set during worklist construction as part of thesystem implementation. For example, a system implementer can choose tohave the case documents and the case audits prefetched, but not the caseevents. This enables the prefetch requirements to be tailored to theenvironment of each specific implementation.

[0062] The worklist is determined based on user identification obtainedwhen the worker logs into the computer system on which the workflowprocessing system is running. BLCaseWorkList 62 calls a collection ofobjects named BLWFWorkListFields 80 formed of objects each namedBLWFWorkListField 82. An object is called by BLWFWorkListField 82 toaccess the workflow engine. The object used will depend on the workflowengine included in the conventional platforms 20. In the exampleillustrated in FIGS. 4A-4C, VWOWorkQuery 83 accesses the Visual WorkFloto obtain information in the workflow platform identifying the fieldsused by a case, such as the name of the worker, the case number, thecase type, the event that caused the case to enter the workflow, thedollar amount, etc.

[0063] Once a worklist has been obtained, the user can select one of thecases on which to work. The GetCase function is called by BLCase Sessionand returns an object called BLCase 64. The BLCase object 64 containsseveral collections of objects to obtain the case information.BLCaseFields 84 is a collection of objects containing the informationfor a case obtained from the database platform in conventional platforms20. For example, the information for an insurance claim may include caseidentification number, incident number, date of incident, name ofinsured, claim dollar amount, type of claim, etc. BLWFWorkItemFields 88is a collection of objects containing information identifying where thecase is in the workflow. The information in BLWFWorkItemFields 88 isobtained from the workflow platform in conventional platforms 20.

[0064] BLCaseEvents 92 is a collection of objects containing informationregarding events that have or will occur during the existence of a case.The events are defined during each system implementation. For example,the receipt of a document in a case, the creation of a new case, and theexpiration of an event tied to a time period may be defined as events ina system. Each system implementation is allowed to create its own eventsby writing an event code to the BL_CaseEvent table by usingBLCase.AddPendingEvent or BLCase.AddReceivedEvent. The Events Processordoes not need to be modified when new event codes are added. Thereceived event codes are matched with the pending event codes by theEvents Processor. As long as the programs writing the event code to theEvents Processor are synchronized such that the program writing thepending event writes the same event code as the program writing thereceived event, the Events Processor will recognize and process theevents. The information contained in BLCaseEvents 92 is obtained fromthe database platform in conventional platforms 20, in a manner similarto that used by BLCaseFields 84.

[0065] The next two objects illustrated in FIGS. 4A-4C are items in acase folder. BLCaseItems 96 represents items that will not havedifferent versions. In the preferred embodiment optical storage is usedfor the data and each BLCaseItem 98 obtains the information by accessingthe optical storage by calling an imaging system object specifically forthe type of optical storage unit used in the system. BLDraftCaseItems100 are documents related to the case that are in process of beingcreated and for which there may be different versions that do not needto be saved on optical storage until the final product has beendetermined. The information in each BLDraftCaseItem 102 is obtained fromthe conventional platforms 20 using the BLCase Object. BLDraftCaseFields104 are the data values stored with a BLDraftCaseItem 102 when the itembecomes permanent.

[0066] In addition to calling the objects illustrated in FIGS. 4A-4C,BLCase 64 also uses several methods to perform operations itself.BLCase.AddNewItem and BLCase.AddNewDraftItem are used to create a newBLCaseItem 98 and a new BLDraftCaseItem 102, respectively.BLCaseWorkList.Prefetch performs the prefetch operations describedabove. BLCase.AddPendingEvent and BLCase.AddReceivedEvent are used tocreate events, as described below.

[0067] BLCaseAuditSessions 108 are a collection of objects used to keeptrack of work performed on a case during the sessions on which the caseis worked. BLCaseAudits 112 are a collection of objects containinginformation about the actions taken during a session. What informationis stored in each BLCaseAudit 114 can be determined when the workflowprocessing system is implemented. The workflow platform in theconventional platforms 20 includes a definition of what information willbe captured by BLCaseAudits 112. In the Visual WorkFlo system used inthe exemplary embodiment, the definition of what information will bestored in BLCaseAudits 112 is determined by each individual systemimplementation. BLCaseAudit 114 defines the interface to write theaudits. Each business application must define and write its own data tothe audit log.

[0068] As an example, a user can suspend a case awaiting a signaturedocument using a module like the Case Manager described below withreference to FIG. 6. The Case Manager module calls theBLCase.AddPendingEvent method with the parameters(EventCode=“ADD_DOC_SIGNATURE_DOC”, EventDescription=“SignatureDocument”, Expire=“current date+10 days”, GroupID=“ ”, GroupEventCode=“”, OptionalEventData=“ ”). This adds a record to the BL_CaseEvent tablethat indicates that the case is waiting for a signature document to bereceived within 10 days or it will be triggered to the user for review.When the document is received, the Case Builder module calls theBLCase.AddReceivedEvent method with the parameters(EventCode=“ADD_DOC_SIGNATURE_DOC”, EventDescription=“SignatureDocument”, Received=“current date”, CaseItemName=“Doc ID”,OptionalEventData=“ ”). This adds a record to the BL_CaseEvent tablethat indicates that the case received a signature document. The nexttime the Events Processor module runs, it matches up the pending andreceived “Signature Document” event codes and triggers the work objectto the user for review.

[0069] Preferably graphical user interfaces (GUIs) in a general purposelanguage like Visual Basic are included in a workflow processing systemaccording to the present invention to provide programmers with the bulkof the code necessary to implement modules like those described above.Examples are Scan, Index, System Maintenance, Case Retrieval, andDocument Retrieval interfaces.

[0070] After incoming documents are prepared for input and sorted intoappropriate batches, operators scan documents in batches into theimaging system. The Scan interface provides a processing window thatrequires users to enter information specific to the current batch. Theuser also has the ability to set properties of the scanner. When themandatory information is entered and the user is satisfied with thesettings, the scan processing window allows the user to start and stopthe actual scanning process.

[0071] The Index interface provides the ability to assign data values toa document for future retrieval. The Scan process dispatches batches toan Index and Reassembly process. When a user starts the Index andReassembly process, the process retrieves a user work list for that userand the divisions within the Index and Reassembly work step. The processloads the first batch in the user's work list onto the Index andReassembly window. The process loads the first document of the batchinto the image viewer and the document is ready for indexing. The actualindex fields displayed for indexing is based on the document class andvaries widely with each system implementation. Therefore, the Indexprocess does not implement the index values control which may, forexample, be an Active X control developed by the organization that usesthe workflow processing system. When a user finishes indexing thedocument, he/she clicks the index button. The Index process saves theindex values for the current document and loads the next document thathas not been indexed.

[0072] The Index and Reassembly process allows for the reassembly ofdocuments in parallel with the indexing of documents. When reassemblingdocuments within a batch, the user may have the ability to adddocuments, delete document separators, mark documents for rescan, movepages, copy pages, and paste pages. These capabilities are easilyprovided when, for example, Visual WorkFlo is used as the workflowengine. The user can view the structure of the batch in the batchreassembly tree to determine whether or not to take these reassemblyactions. For example, some fax transmissions are received as onetransmission but contain several documents. There is no exact method todetermine the document breaks within a single transmission. The indexerreviews each batch and adds new documents as necessary. The indexer canthen move pages into the newly created documents.

[0073] When the user indexes all documents in the current batch, theprocess prompts the user to commit the batch. If the user chooses tocommit the batch, then the process commits the batch and loads the nextbatch in the user's work list. If the user chooses not to commit thebatch, the user is allowed to continue re-indexing documents orreassembling the batch until the user is ready to commit via the commitbatch menu option.

[0074] The System Maintenance interface is a program that is customizedfor each system implementation. While some of the code is very specificto an implementation, e.g., specific edit checks, some things remain thesame. There is always a set of baseline tables that have a constanttable structure and there is a framework for selecting and displayingtable information. Therefore code for these functions is preferablyprovided by a workflow processing system according to the presentinvention.

[0075] The System Maintenance interface has two basic screens. The firstis the main window, which has a picture list-box down the left-hand sideand a grid control covering the remainder of the window. The windowcreates itself dynamically from a set of constant data structures whichlists the icon to be shown in the picture list-box as well as the fieldsin the corresponding table to be show in the grid for that selection.The second window is a sample property-tabbed dialog that the user usesto update any of the values from the grid. No data is actually modifiedin the grid. BLErrorLog 72, CNativeErrorLog (not shown), BLStatLog 74,BLDebugLog 70, CNativeDebugLog (not shown), BLDBConnMgr 66 andBLProgramSecurity 76 are used.

[0076] Document Retrieval is also a commonly requested interface.Although the actual window that users view from implementation toimplementation differs, the basics of creating and executing a queryagainst the imaging platform in the conventional platforms 20 are verysimilar. A workflow processing system according to the present inventionpreferably provides a program that implements the basics of taking aquery and executing it against the imaging platform in the conventionalplatforms 20.

[0077] Document Retrieval (and Case Retrieval) preferably useconventional protocols of the operating system for selecting files. Aninterface is preferably included in the basic workflow processing systemto provide a simple search criteria window. When the user clicks Search,the program preferably uses the workflow engine in the conventionalplatforms 20, e.g., FileNET's OLEDB provider to retrieve a list ofdocuments using an ADODB.RecordSet object 118 (FIG. 4A). The contents ofthe record set will fill the expanded window with a grid of documentindices. Users may then select a document and view it in the workflowengine's native viewer interface.

[0078] Document Retrieval will make full use of the BLErrorLog,CNativeErrorLog, BLStatLog, BLDebugLog, CNativeDebugLog, BLDBConnMgr andBLProgramSecurity objects. The majority of the code will be implementedin a COM object to allow other programs to include Document Retrievalcapabilities within their operations.

[0079] Although Case Retrieval has slightly more variation from onesystem implementation to another than Document Retrieval, the basics arestill the same. The window in Case Retrieval will look very similar toDocument Retrieval. There will be a simple search criteria windowallowing the user to enter specific case data values. After clickingsearch, the main window will expand to show a grid with case data forany matching cases.

[0080] The Index, Document Retrieval, and Case Retrieval interfaces areimplemented with common functions and features and may be implementedwith a basic interface control that provides sample search datacapabilities. Each specific implementation modifies this interfacecontrol without changing the rest of the application or re-compiling theapplication.

[0081] The GUI can be thought of as a standalone program, a menu optionin a case management GUI, or as the beginnings of a Balance WorkLoadprocess, where managers multi-select from the list of found cases andreassign them or prompt them into the workflow (Unpend any PENDEDitems).

[0082] Case Retrieval makes full use of the BLErrorLog, CNativeErrorLog,BLStatLog, BLDebugLog, CNativeDebugLog, BLDBConnMgr, BLProgramSecurity,BLCaseSession and BLCase objects. The majority of the code is preferablyimplemented in a COM object to allow other programs to include CaseRetrieval capabilities within their operations.

[0083] As discussed above, a letter generation wizard is preferablyincluded to provide a graphical user interface that steps a user throughthe creation of a custom letter. It is usually called from a CaseManager process that is customized for each client. The lettergeneration wizard interfaces with a word processing program in theconventional platforms 20, such as Microsoft Word. It allows the user toselect from a list of letter templates. Once a letter template isselected, the wizard reads the template in, e.g., Microsoft Word, foreach bookmark and displays the bookmarks in a window for the user tofill in. The wizard replaces the bookmark values with the providedvalues and sizes the fields according to user defined sizeconfigurations for each field. Macros within the template allow the userto finish the letter and return to the Case Manager process. After theCase Manager process, the work object is sent to the Draft LetterCommittal background process which commits the letter to the imagingsystem and adds the letter to the case folder.

[0084] Illustrated in FIG. 5 is an example of how the Events Processorand Queue Assignment modules operate. When an event is detected, asindicated by Event Trigger 120, the Events Processor determines how thework item(s) 122 associated with the event should be started through theworkflow and what data to start in the workflow. The workflow dictatesthe work step 124. The Queue Assignment module then determines to whichwork division 126 the work item(s) 122 should be assigned. Theconfiguration tables are used by the Events Processor and QueueAssignment modules to perform these tasks.

[0085] One example of tables that could be used in the present inventionis provided below. This is merely one example of many possible ways thattables could be used to minimize the extent that programs have to bemodified during system implementation.

[0086] The Case table (BL_CASE) is the main processing table. It storesa record for each case per work type in the system. It is accessed byBLCase 64. There can be multiple case tables in the system. The tablestructure is always modified for each system implementation. Below isone example. BL_CASE ( SCASEID VARCHAR2(16) not null, SWORKTYPEVARCHAR2(16) not null, SSTATUS VARCHAR2(16) not null, SOWNERIDVARCHAR2(16) null , DCREATED DATE not null, SLASTUPDATEUSERIDVARCHAR2(16) null , DLASTUPDATED DATE null , SACCOUNTNUM VARCHAR2(32)null , )

[0087] The Case Event table (BL_CASEEVENT) stores all the received andpending events associated with cases. It is written to and read from byBLCaseEvents 92. BL_CASEEVENT ( SWORKTYPE VARCHAR2(16) not null, SCASEIDVARCHAR2(16) not null, SEVENTCODE VARCHAR2(32) not null, SEVENTSTATECHAR(1) not null, SEVENTDESC VARCHAR2(256) not null, DEXPIRE DATE null ,SGROUPID VARCHAR2(16) null , SGROUPEVENTCODE VARCHAR2(32) null ,SPROCESSINGSTATUS CHAR(1) not null, DRECEIVED DATE null , SCASEITEMNAMEVARCHAR2(64) null , SOPTIONALEVENTDATA VARCHAR2(128) null , DCREATEDDATE not null, )

[0088] The Case Item table (BL_CASEITEM) stores the reference to theitems associated with cases. For example, the reference number fordocuments associated with cases are stored in the table. BLCaseItems 96accesses the table. BL_CASEITEM ( SCASEID VARCHAR2(16) not null,SWORKTYPE VARCHAR2(16) not null, SITEMNAME VARCHAR2(64) not null,SITEMDISPLAYNAME VARCHAR2(128) null , IITEMTYPE NUMBER(4) not null,DCREATED DATE not null, )

[0089] The Draft Case Item table (BL_DRAFTCASEITEM) stores the draftitems and data associated with cases. For example, the binary draftdocuments associated with cases are stored in the table.BLDraftCaseItems 100 accesses the table. BL_DRAFTCASEITEM ( SCASEIDVARCHAR2(16) not null, SWORKTYPE VARCHAR2(16) not null, SDRAFTITEMNAMEVARCHAR2(64) not null, SDRAFTITEMDISPLAYNAME VARCHAR2(128) null ,SDOCUMENTCLASS VARCHAR2(32) not null, SDRAFTITEMTYPE VARCHAR2(64) notnull, SINDEXVALUES VARCHAR2(2000) null , BITEMDATA LONG RAW null ,DCREATED DATE not null, )

[0090] The Case Lock table (BL_CASELOCK) stores the cases that arecurrently locked for processing by any program module. BLCaseSession 60creates and deletes the case lock records. BL_CASELOCK ( SCASEIDVARCHAR2(16) not null,  SWORKTYPE VARCHAR2(15) not null, SUSERIDVARCHAR2(16) not null, DLOCKED DATE not null, )

[0091] The Case Relationship table (BL_CASERELATIONSHIP) stores therelationship between cases. It is accessed by the BLCase object usingthe GetChildren and GetParent methods. BL_CASERELATIONSHIP (SCHILDCASEID VARCHAR2(16) not null, SCHILDWORKTYPE VARCHAR2(16) notnull, SPARENTCASEID VARCHAR2(16) not null, SPARENTWORKTYPE VARCHAR2(16)not null, DCREATED DATE not null, )

[0092] The Case Audit Session table (BL_CASEAUDITSESSION) is the parenttable for all audits during a case session. It is accessed byBLCaseAuditSession 110. BL_CASEAUDITSESSION ( SWORKTYPE VARCHAR2(16) notnull, SCASEID VARCHAR2(16) not null, SSESSIONID VARCHAR2(16) not null,DCREATED DATE not null, SUSERID VARCHAR2(16) not null, )

[0093] The Scan Productivity table (BL_SCANPRODUCTIVITY) is a processingtable used to store the statistics to run a productivity report for scanoperators. The table records are written by the Scan interface(described below) and are not modified by any other process.BL_SCANPRODUCTIVITY ( SBATCHNAME VARCHAR2(18) null , BBATCHACCEPTEDCHAR(1) null , SUSERID VARCHAR2(8) null , DRECEIVEDDATE DATE null ,IEXPECTEDCOUNT NUMBER(3) null , IACTUALCOUNT NUMBER(3) null , IPAGECOUNTNUMBER(3) null , SDOCTYPE VARCHAR2(20) null , DSCANSTARTTIME DATE null ,DSCANSTOPTIME DATE null , )

[0094] The Index Productivity table (BL_INDEXPRODUCTIVITY) is aprocessing table used to store the statistics to run a productivityreport for index operators. The table records are written by the Indexinterface (described below) and are not modified by any other process,but are used for reporting purposes. BL_INDEXPRODUCTIVITY ( SBATCHNAMEVARCHAR2(18) null , SUSERID VARCHAR2(8) null , IDOCUMENTCOUNT NUMBER(3)null , INUMBERINDEXED NUMBER(3) null , INUMBERRESCANNED NUMBER(3) null ,INUMBERADDED NUMBER(3) null , INUMBERDELETED NUMBER(3) null , DSTARTTIMEDATE null , DSTOPTIME DATE null , )

[0095] The Rescan table (BL_RESCAN) is a processing table that storesdocuments that need to be rescanned. The table records are written bythe Index interface and are not modified by any other process. BL_RESCAN( SDOCID VARCHAR2(8) null , SBATCHNAME VARCHAR2(18) null , SUSERIDVARCHAR2(8) null , INUMBERPAGES NUMBER(3) null , SPAGEPOSITIONVARCHAR2(25) null , SDOCTYPE VARCHAR2(20) null , DRESCANTIME DATE null ,)

[0096] The Document Type table (BL_DOCTYPE) stores the valid businessdocument types and their associated scan settings. This table isaccessed by the Scan and Index graphical user interfaces. The Scan andIndex interfaces use the table to provide a list of valid document typesto the user. Once a valid document type is chosen, the Scan programlooks up the associated settings and template to which to attach thescan batch. This table can be modified by business users through theSystem Maintenance interface (described below). BL_DOCTYPE ( SDOCTYPEVARCHAR2(20) not null, SSETTINGS VARCHAR2(20) not null, STEMPLATEVARCHAR2(20) null , )

[0097] The Case Audit Detail table (BL_CASEAUDITDETAIL) stores auditrecords created for each case. It is accessed by BLCaseAudit 114.BL_CASEAUDITDETAIL ) SSESSIONID VARCHAR2(16) not null, DCREATED DATE notnull, SCATEGORY VARCHAR2(16) not null, SACTION VARCHAR2(16) not null,SDESCRIPTION VARCHAR2(512) null , SAUDITDETAIL1 VARCHAR2(64) null ,SAUDITDETAIL2 VARCHAR2(64) null , SAUDITDETAIL3 VARCHAR2(64) null , )

[0098] A set of baseline tables need to be configured for eachimplementation of the present invention. Each system implementationbuilds upon this framework to add its own tables. The baseline tablesthat need to be configured are: BL_USERPROFILE BL_PROGRAMSECURITYBL_TASKSECURITY BL_FUNCTIONSECURITY BL_USERWORKLOAD BL_USERWORKSTEPBL_USERWORKSTEPDIVISION BL_WORKTYPE BL_WORKSTEP BL_WORKSTEPDIVISIONBL_WORKSTEPRULE BL_BOOKMARKCONFIG BL_BOOKMARKMAP BL_DOCTYPEMAPBL_UPDATEORDER BL_SYSTEMPARAM BL_EVENTPROCFIELDMAP BL_LETTERBL_LETTERGROUP

[0099] In addition, there will almost always be a set of businessspecific tables at each site.

[0100] The User Profile table (BL_USERPROFILE) is a reference table thatstores all the users in the system and their associated characteristics.The User Distribution process accesses the User Profile table todetermine whether a user is available to receive work. BL_USERPROFILE (SUSERID VARCHAR2(8) not null, SUSERNAME VARCHAR2(64) not null,BISAVAILABLE CHAR(1) not null, )

[0101] The Program Security table (BL_PROGRAMSECURITY) stores the firstlevel of security, the program module level. BLProgramSecurity 76accesses the table. The table records are maintained by business usersthrough the System Maintenance interface. BL_PROGRAMSECURITY ( SUSERIDVARCHAR2(8) not null, SPROGRAMNAME VARCHAR2(16) not null, )

[0102] The Task Security table (BL_TASKSECURITY) stores the second levelof security, the task level. BLProgramSecurity 76 accesses the table.The table records are maintained by business users through the SystemMaintenance interface. BL_TASKSECURITY ( SUSERID VARCHAR2(8) not null,SPROGRAMNAME VARCHAR2(16) not null, STASKNAME VARCHAR2(16) not null, )

[0103] The Function Security table (BL_FUNCTIONSECURITY) stores thethird level of security, the function level. BLProgramSecurity 76accesses the table. The table records are maintained by business usersthrough the System Maintenance interface. BL_FUNCTIONSECURITY ( SUSERIDVARCHAR2(8) not null, SPROGRAMNAME VARCHAR2(16) not null, STASKNAMEVARCHAR2(16) not null, SFUNCTIONNAME VARCHAR2(16) not null, )

[0104] The User Work Load table (BL_USERWORKLOAD) stores the relativeload that each user should be assigned during the User Distributionprocess. The records in the table are maintained by business usersthrough the System Maintenance interface. BL_USERWORKLOAD ( SUSERIDVARCHAR2(8) not null, SWORKTYPE VARCHAR2(16) not null, ILOADFACTORNUMBER(4) not null, )

[0105] The User Work Step table (BL_USERWORKSTEP) defines the work stepsthat a user is allowed to access. BL_USERWORKSTEP ( SUSERID VARCHAR2(8)not null, SWORKTYPE VARCHAR2(16) not null, SWORKSTEP VARCHAR2(16) notnull, )

[0106] The User Work Step Division table (BL_USERWORKSTEPDIVISION)stores the order of work step divisions in which a user receives work.BLCaseSession 60 accesses this table using the GetUserWorkList method.BL_USERWORKSTEPDIVISION ( SUSERID VARCHAR2(8) not null, SWORKTYPEVARCHAR2(16) not null, SWORKSTEP VARCHAR2(16) not null, SWORKSTEPDIVVARCHAR2(16) not null, IWORKSTEPDIVPRIORITY NUMBER(2) not null, )

[0107] The Work Type table (BL_WORKTYPE) stores each different type ofwork in the system. A work type is defined as the data and processesassociated with work. The parameters associated with each work typedescribe the database table and the workflow engine class that should beaccessed for processing. Work Types are associated with a specificBLCase Table and the system can support multiple Work Types. BL_WORKTYPE( SWORKTYPE VARCHAR2(16) not null, SWORKTYPENAME VARCHAR2(64) not nullSCASETABLENAME VARCHAR2(64) not null, SWORKELOWOLASS VARCHAR2(64) null ,BPROCESSMULTIPLEEVENTS CHAR(1) null , )

[0108] The Work Step table (BL_WORKSTEP) stores all the work stepsassociated with a work type. The work steps must also correspond to theworkflow engine process map. There are characteristics about work stepsthat are captured in this table. The table is configured initiallyduring system implementation. It is not changed often during the life ofthe system. BL_WORKSTEP ( SWORKTYPE VARCHAR2(16) not null, SWORKSTEPVARCHAR2(16) not null, SWORKSTEPNAME VARCHAR2(64) not null BISSYSTEMSTEPCHAR(1) not null, BISFILTERED CHAR(1) not null, BISEVENTALLOWED CHAR(1)not null, SWORKFLOWPERFORMERNAME VARCHAR2(64) null , SEVENTACTIONCODECHAR(1) null , )

[0109] The Work Step Division table (BL_WORKSTEPDIVISION) stores thework step divisions associated with each work type and work stepcombination. Work Step Divisions are segmentations of Work Steps thatprovide work specialization. The records are maintained by businessusers through the System Maintenance interface. BL_WORKSTEPDIVISION (SWORKTYPE VARCHAR2(16) not null, SWORKSTEP VARCHAR2(16) not null,SWORKSTEPDIV VARCHAR2(16) not null, SWORKSTEPDIVNAME VARCHAR2(64) notnull, IWORKSTEPDIVTYPE NUMBER(1) not null, BISDEFAULT CHAR(1) not null,)

[0110] The Work Step Rule table (BL_WORKSTEPRULE) stores the rulesassociated with work step divisions. The rules are prioritized to readand determine to which work step division a case should be assigned.These rules may be maintained by business users through the SystemMaintenance interface. BL_WORKSTEPRULE ( SWORKTYPE VARCHAR2(16) notnull, SWORKSTEP VARCHAR2(16) not null, IWORKSTEPRULENUM NUMBER(4) notnull, SWORKSTEPRULE VARCHAR2(2000) not null, SNEWWORKSTEPDIVVARCHAR2(16) not null, BDISABLED CHAR(1) not null, )

[0111] The Book Mark Configuration table (BL_BOOKMARKCONFIG) stores theheight and width of each letter field. It is accessed by the LetterGeneration Wizard to size each bookmarked field when presenting the dataentry screen to a user. This table is optional and is managed bybusiness users through the System Maintenance interface.BL_BOOKMARKCONFIG ( SBOOKMARKNAME VARCHAR2(64) not null, IHEIGHTNUMBER(2) null , IWIDTH NUMBER(2) null , )

[0112] The Book Mark Map table (BL_BOOKMARKMAP) stores the associationbetween a letter bookmark and the case field that should be assigned toit. The Letter Generation Wizard uses the table to query by the bookmarkname and replace the bookmark with the specified case field value.BL_BOOKMARKMAP ( SBOOKMARK VARCHAR2(64) not null, SWORKTYPE VARCHAR2(16)not null, SFIELDNAME VARCHAR2(64) not null, IFIELDTYPE NUMBER(2) notnull, )

[0113] The Doc Type Map table (BL_DOCTYPEMAP) maps an incoming documenttype to a work type. This table is accessed by the Case Builder process.BL_DOCTYPEMAP ( SDOCTYPE VARCHAR2(16) not null, SWORKTYPE VARCHAR2(16)not null, )

[0114] The Update Order table (BL_UPDATEORDER) dictates the order inwhich tables should be updated for a transaction. DBConnMgr 66 accessesthis table to commit records in the correct order. This table isconfigured during system implementation and is not changed very oftenduring the life of the system. It is modified by a knowledgeable systemadministrator or programmer. BL_UPDATEORDER ( IORDER NUMBER not null,STABLENAME VARCHAR2(64) not null, )

[0115] The System Parameter table (BL_SYSTEMPARAM) stores system wideparameters. It is accessed by each program module. BL_SYSTEMPARAM (SPARAMNAME VARCHAR2(32) not null, SPRAMVALUE VARCHAR2(256) null , )

[0116] The Event Process Field Map table (BL_EVENTPROCFIELDMAP) storesthe work object fields that are created when a work object is injectedinto the workflow engine. There are different mappings for each worktype. The table provides a configurable method to map fields to the workobject before it is injected into the workflow. This is determined ateach system implementation without needing to modify code. It isaccessed by the Event Processor module. BL_EVENTPROCFIELDMAP (SFIELDNAME VARCHAR2(64) not null, IFIELDTYPE NUMBER(2) not null,SWORKITEMFIELDNAME VARCHAR2(64) not null, SWORKTYPE VARCHAR2(16) notnull, )

[0117] The Letter table (BL_LETTER) stores all the letter templates inthe system and their associated characteristics. They are associatedwith the Letter Group table. The Letter Generation Wizard accesses thetable to retrieve all the letter templates into a list given a lettergroup. The table is maintained by business users through the SystemMaintenance interface. BL_LETTER ( SGROUPID VARCHAR2(16) not null,SLETTERID VARCHAR2(16) not null, SLETTERDISPLAYNAME VARCHAR2(128) notnull, SLETTERFILENAME VARCHAR2(32) not null, IDISPLAYORDER NUMBER(4) notnull, )

[0118] The Letter Group table (BL_LETTERGROUP) stores the list of lettertemplates grouped in business groups. The Letter Generation Wizard readsthis table to display the list of valid tables for the user to selectfrom. The Letter Group table is maintained by business users through theSystem Maintenance interface. BL_LETTERGROUP ( SGROUPID VARCHAR2(16) notnull, SGROUPDISPLAYNAME VARCHAR2(128) not null, IDISPLAYORDER NUMBER(4)not null, )

[0119] An example of workflow processing in a workflow processing systemaccording to the present invention is illustrated in FIG. 6. Duringsystem implementation, the base workflow process flow is defined in theworkflow platform in the conventional platforms 20 using a workflowengine like FileNET Visual WorkFlo. Data Capture 130 may be aconventional process that places information to be used in electronicform. Imaging of documents, input of data from a database, input oftransactional data, etc. are included. The Case Builder 132 organizesthe information according to rules in the workflow platform in theconventional platforms 20 and stores links to the data in conventionaldatabases, data warehouses, etc. where the information is stored in theconventional platforms 20 by Data Capture 130. The Events Processor 134is initially executed to place the new case in the first work step 124.The Queue Assignment module 136 is then executed to place the case inthe appropriate work queue or work step division, as discussed abovewith respect to FIG. 5. If the work step division requires 138 a case tobe “owned” by a user, the user distribution module 140 is executed toassign ownership. Regardless of whether the case has been assigned to aparticular user, Case Manager 142 could be executed next. Case Manager142 is uniquely created for each system implementation. Case Manager 142may be created using development tools such as Visual Basic or VisualC++. The case objects described with reference to FIGS. 4A-4C are usedto quickly develop the code for Case Manager 142.

[0120] If a letter is created in step 144, BLCase creates a newBLDraftCaseItem object 102. If it is desirable to convert the letter toTIFF format before committal to permanent storage on, e.g., an opticaldisk, the draft case item is sent to the Draft Committal process 146 forconversion of the letter to TIFF format and storage on, e.g., theoptical disk. This process also changes the draft case item to a regularcase item. Processing then continues as defined for the specificbusiness application in the workflow engine and therefore, the specificprocessing is not illustrated in FIG. 6. Typically, the object issuspended for additional information, destroyed because the case isdone, or routed to another user.

[0121] Preferably, at various times during work on a case, a check ismade 148 to determine whether the case should be sent to QualityAssurance. If so, the Queue Assignment module 150 is called to place thecase in a work division 126 for case quality assurance review 152.

[0122] As illustrated in FIG. 7, the present invention can beimplemented on a conventional general purpose computer system, includinga processor 202, memory unit 204 and input/output unit 206. Whenimplemented on an enterprise basis, there will likely be a plurality ofprocessors, memory units and very many input/output units, such asdesktop or notebook computers (not shown). These devices are likely tobe networked, possibly using multiple network protocols. Any suitableconventional hardware and software can be used to provide the computersystem, including distributed processing, intranets, personal computers,etc.

[0123] The present invention has been described with respect toexemplary embodiments of a workflow processing framework, workflowdevelopment system and workflow processing system. However, theinvention is not limited to these specific embodiments, but encompassesall of the subject matter of the following claims.

[0124] The many features and advantages of the invention are apparentfrom the detailed specification and, thus, it is intended by theappended claims to cover all such features and advantages of theinvention which fall within the true spirit and scope of the invention.Further, since numerous modifications and changes will readily occur tothose skilled in the art, it is not desired to limit the invention tothe exact construction and operation illustrated and described, andaccordingly all suitable modifications and equivalents may be resortedto, falling within the scope of the invention.

[0125] Reference will now be made in detail to the embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings, wherein like reference numerals refer to like elementsthroughout. The embodiments are described below in order to explain thepresent invention by referring to the figures.

What is claimed:
 1. A workflow processing framework, scalable for use bya single department to an entire enterprise, comprising: a set ofsoftware objects, each unique throughout the enterprise, supportingcorresponding business functions; a database, accessed by a subset ofthe software objects, defining work taxonomy and work steps for workflowprocessing; and a workflow engine utilizing the software objects and thework taxonomy to perform the workflow processing, wherein the workflowprocessing framework defines work step divisions for at least one of thework steps.
 2. The workflow processing framework as recited in claim 1wherein the work step divisions for the at least one of the work stepsare prioritized when presented to a user.
 3. A workflow processingframework, scalable for use by a single department to an entireenterprise, comprising: a set of software objects, each uniquethroughout the enterprise, supporting corresponding business functions;a database management system, accessed by a subset of the softwareobjects, defining work taxonomy and work steps for workflow processing,wherein the database management system comprises a workflow engineutilized by the set of software objects and the subset of the softwareobjects using the work taxonomy to perform the workflow processing andutilized by the workflow processing framework in combination with thedatabase management system to perform case processing, the workflowprocessing framework defining work step divisions for at least one ofthe work steps, wherein the work step divisions correspond to componentprocesses defined by work step rules and assigning a case to a work stepdivision based on case data and the work step rules associated with thework step and assigning the case to a user based on work load computedusing case data and a work load factor in the database management systemwhen the work step division is a user type.
 4. A workflow processingframework, scalable for use by a single department to an entireenterprise, comprising: a business process layer using a common objectslayer to perform enterprise specific functions; a common objects layerproviding common case and workflow processing functions to supportdifferent applications and to abstract out information about theconventional platform used; a conventional platforms layer comprising aworkflow engine and a database; and a foundation objects layer providingcommunications between the common objects and the workflow engine,wherein the database and workflow engine, accessed by the foundationobjects, define work taxonomy and work steps for workflow processing,and the workflow processing framework define work step divisions for atleast one of the work steps.
 5. The workflow processing framework asrecited in claim 5, wherein the work step divisions for the at least oneof the work steps are prioritized when presented to a user.
 6. Theworkflow processing framework as recited in claim 4, wherein theworkflow engine, the database, and the layers allow the workflowprocessing framework to operate across business functions.
 7. Theworkflow processing framework as recited in claim 4, wherein thefoundation object layer and the conventional platform layer allow theworkflow processing framework to operate across different workflowengines.
 8. The workflow processing framework as recited in claim 4,wherein the database comprises user-definable tables comprising baselinetables for the workflow processing framework and business specifictables defined for each department.
 9. The workflow processing frameworkas recited in claim 8, wherein the baseline tables and the businessspecific tables allow the workflow processing framework to operateacross different departments.